跳到主要内容

Token 鉴权

Token 鉴权​

现在我们已经得知，Session-Cookie 的一些缺点，以及 Session 的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。那有没有更好的办法？

于是 Token 就应运而生了

Token（令牌）​

Token 是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。一句话概括：访问资源接口（API）时所需要的资源凭证

Token 的组成​

一般 Token 的组成由 uid （用户唯一的身份标识）+ time（当前时间的时间戳) + sign （签名，Token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）

Token 的认证流程图​

Token 的认证流程图

Token 认证步骤解析​

  1. 客户端： 输入用户名和密码请求登录校验。
  2. 服务器： 收到请求验证用户名与密码；验证成功后，服务端会签发一个 Token，并把这个 Token 发送给客户端。
  3. 客户端： 收到 Token 以后需要把它存储起来，Web 端一般会放在 localStorage 或 Cookie 中，移动端原生 APP 一般存储在本地缓存中。
  4. 客户端： 再次向服务端请求 API 资源的时候，将 Token 通过 HTTP 请求头 Authorization 字段或者其它方式发送给服务端。
  5. 服务器： 收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据，否则拒绝返还（401）。

Token 的优点​

  • 服务端无状态化、可扩展性好： Token 机制在服务端不需要存储会话（Session）信息，因为 Token 自身包含了其所标识用户的相关信息，这有利于在多个服务间共享用户状态。
  • 支持 APP 移动端设备。
  • 安全性好： 有效避免 CSRF 攻击（因为不需要 Cookie）。
  • 支持跨程序调用： 因为 Cookie 是不允许跨域访问的，而 Token 则不存在这个问题。

Token 的缺点​

  • 配合： 需要前后端配合处理。
  • 占带宽： 正常情况下比 sid 更大，消耗更多流量，挤占更多宽带。
  • 性能问题： 虽说验证 Token 时不用再去访问数据库或远程服务进行权限校验，但是需要对 Token 加解密等操作，所以会更耗性能。
  • 有效期短： 为了避免 Token 被盗用，一般 Token 的有效期会设置的较短，所以就有了 Refresh Token。

Refresh Token（刷新 Token）​

业务接口用来鉴权的 Token，我们称之为 Access Token。为了安全，我们的 Access Token 有效期一般设置较短，以避免被盗用。但过短的有效期会造成 Access Token 经常过期，过期后怎么办呢？

一种办法是刷新 Access Token，让用户重新登录获取新 Token，会很麻烦。另一种办法是再来一个 Token，一个专门生成 Access Token 的 Token，我们称为 Refresh Token。

  • Access Token： 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活；
  • Refresh Token： 用来获取 Access Token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 Session 一样处理；

Refresh Token 的认证流程图​

Refresh Token 的认证流程图

Refresh Token 认证步骤解析​

  1. 客户端： 输入用户名和密码请求登录校验。
  2. 服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；
  3. 客户端： 把 Access Token 和 Refresh Token 存储在本地；
  4. 客户端： 请求数据时，携带 Access Token 传输给服务端；
  5. 服务端：
    • 验证 Access Token 有效：正常返回数据
    • 验证 Access Token 过期：拒绝请求
  6. 客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；
  7. 服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
  8. 客户端： 重新携带新的 Access Token 请求接口；

Session-Cookie 和 Token 有很多类似的地方，但是 Token 更像是 Session-Cookie 的升级改良版。

  • 存储地不同： Session 一般是存储在服务端；Token 是无状态的，一般由前端存储。
  • 安全性不同： Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击。
  • 支持性不同： Session-Cookie 认证需要靠浏览器的 Cookie 机制实现，如果遇到原生 NativeAPP 时这种机制就不起作用了，或是浏览器的 Cookie 存储功能被禁用，也是无法使用该认证机制实现鉴权的；而 Token 验证机制丰富了客户端类型。